The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Transmission Control Protocol (TCP) as described in IETF RFC 793 defines transport-layer messages that network nodes may communicate to achieve guaranteed data delivery and implement flow control. TCP data packets include a header carrying a segment sequence number that a receiver can use to determine whether the receiver has received all segments from a sender. Valid segments must have a sequence number falling in a changeable range defined as the receiver's sliding receive window. Different implementations can use receive windows of different sizes.
Varying network conditions can cause loss or delay of segments in a stream of segments that a sender sends a receiver. When a TCP implementation at the receiver receives segments bearing a sequence number higher than the highest previously acknowledged segment, the receiver stores the newly received segments in a reassembly queue for later processing after earlier missing segments arrive.
When too many out-of-order segments arrive on a TCP connection, and the receive window of a TCP implementation is large, then the TCP implementation is vulnerable to an attack consisting of a flood of spoofed segments. The receive window of an application might be large when an application uses large data records, or in applications that traverse satellite links or links in other so-called “long fat networks” in which delays are longer or more drops occur than with other kinds of links. Receive window scaling is described in V. Jacobson et al., “TCP Extensions for High Performance,” IETF RFC 1323 (1992).
Since an incoming segment is more likely to be accepted if the receive window is large, vulnerability increases with window size. If the number of spoofed and received out-of-order segments is excessively large, then the reassembly queue can overflow. Alternatively, if a TCP implementation allocates more memory for the reassembly queue as more out-of-order segments arrive and overflow approaches, then eventually the TCP implementation may run out of memory. The result would be resource exhaustion and a successful denial of service (DOS) attack.
Further, in certain approaches in which segments are placed in the reassembly queue by writing a pointer to the segment in an interface input queue, overflow of the reassembly queue also may cause resource exhaustion at the interface input queue. This condition may trigger slow-start approaches in protocols such as UDP that are using the same interface but not associated with the problem condition. Resource starvation of all protocols that are using the interface may occur.
The same problem may arise when too many genuine out-of-order segments arrive. In that case, for efficient management of resources such as packet memory, then queuing too many segments is undesirable. However, it may be difficult to determine whether received segments are genuine or spoofed.
Known TCP stacks do not limit the size of the TCP reassembly queue. Implementing a hard-coded limit on the reassembly queue is inefficient, especially for applications that must use a large receive window size, or for applications in which the receive window is typically an order of magnitude larger than the normal window size. U.S. application Ser. No. 10/815,218, filed Mar. 30, 2004, entitled “Preventing network data injection attacks using duplicate-ACK and reassembly gap approaches,” of Anantha Ramaiah et al., describes how to discard the “fake” data in the re-assembly queue.